Agile Bug Tracking
Jorge Ferreira
PART 1
ETL
The datasets provided (issues and issuesHistory csv files) need to be cleaned and loaded into the database, so any business user can properly investigate them by simply using a SQL query or export them for a deeper analysis.
library(readr)
issues <- read.csv("~/Desktop/issues.csv")
head(issues)## Project Key Created Status Type
## 1 TAL TAL-1044 10/05/2018, 10:52 Waiting UX / Design Story
## 2 TAL TAL-1043 04/07/2018, 16:06 To Do Story
## 3 TAL TAL-1042 04/07/2018, 15:11 In Progress Story
## 4 TAL TAL-1041 04/07/2018, 15:09 To Do Story
## 5 TAL TAL-1040 04/07/2018, 08:00 To Do Story
## 6 TAL TAL-1039 04/07/2018, 07:52 To Do StoryStarting with the issues.csv file… Does it have any missing data?
sum(is.na(issues))## [1] 0length(duplicated(issues)[duplicated(issues)=="TRUE"])## [1] 0There are no missing values and all observations are unique. But dates in Created are not in the right format, so that needs to be amended.
issues$Created <- gsub(",","",issues$Created)
issues$Created <- as.POSIXct(issues$Created, format = "%d/%m/%Y %H:%M", tz="GMT")
issues$Key <- as.character(issues$Key)
str(issues)## 'data.frame': 4247 obs. of 5 variables:
## $ Project: Factor w/ 5 levels "CVAL","DFO","DW",..: 5 5 5 5 5 5 5 5 5 5 ...
## $ Key : chr "TAL-1044" "TAL-1043" "TAL-1042" "TAL-1041" ...
## $ Created: POSIXct, format: "2018-05-10 10:52:00" "2018-07-04 16:06:00" ...
## $ Status : Factor w/ 14 levels "Blocked","Candidate - Estimate Requested",..: 14 13 6 13 13 13 13 7 5 9 ...
## $ Type : Factor w/ 11 levels "Bug","Bug - Sub-Task",..: 8 8 8 8 8 8 8 1 1 1 ...In total, there were 4247 issues created between 2016-03-23 14:36:00 and 2018-07-06 11:03:00. And the issues.csv file is ready to be loaded into the DB.
write.csv(issues, "~/Desktop/READYissues.csv", row.names = FALSE, quote = FALSE)Now let’s take a look at the issuesHistory.csv file and see what kind of cleaning it requires. As the file was being read into R, I identified a typo in row number 11918 which prevented it to proceed properly. So, I fixed it manually, saved it as issuesHistory.xlsx and used the read_xlsx function from the readxl library.
library(readxl)
history <- read_xlsx("~/Desktop/Tests/Outsystems/issuesHistory.xlsx")
history <- as.data.frame(history)Dates in Created have the same format problem as in the issues file, so will treat them the same way.
history$Created <- gsub(",","",history$Created)
history$Created <- as.POSIXct(history$Created, format = "%d/%m/%Y %H:%M", tz="GMT")
str(history)## 'data.frame': 18011 obs. of 10 variables:
## $ Issue : chr "TAL-1044" "TAL-1044" "TAL-1044" "TAL-1042" ...
## $ History Id : num 1220713 1220710 1220545 1218163 1218162 ...
## $ Author : chr "ase" "ase" "ase" "paulo.junior" ...
## $ Created : POSIXct, format: "2018-07-05 12:09:00" "2018-07-05 12:09:00" ...
## $ Field : chr "status" "status" "status" "status" ...
## $ Type : chr "jira" "jira" "jira" "jira" ...
## $ From : num 10001 12400 10001 10401 14800 ...
## $ From String: chr "To Do" "Done" "To Do" "Ready" ...
## $ To : num 13900 10001 12400 11702 10401 ...
## $ To String : chr "Waiting UX / Design" "To Do" "Done" "In Progress" ...Now let’s investigate the dataset further. Does it have missing values?
sum(is.na(history))## [1] 19history[rowSums(is.na(history)) > 0, colSums(is.na(history)) > 0]## History Id Created Field Type From
## 11918 1008968 2018-01-30 16:32:00 status jirimate Request 10401
## 11919 1008967 2018-01-30 16:32:00 status jira 10001
## 13167 NA <NA> <NA> <NA> NA
## 13993 NA <NA> <NA> <NA> NA
## From String To To String
## 11918 Ready NA <NA>
## 11919 To Do 1480 <NA>
## 13167 <NA> NA <NA>
## 13993 <NA> NA <NA>This time we have 19 missing values across 4 observations. The first two rows belong to Issue DFO-444. Allow me to check out all its records as we might find a way to fill in those NAs.
history[history$Issue=="DFO-444",]## Issue History Id Author Created Field
## 11917 DFO-444 1019807 cia 2018-02-06 19:40:00 status
## 11918 DFO-444 1008968 epe 2018-01-30 16:32:00 status
## 11919 DFO-444 1008967 epe 2018-01-30 16:32:00 status
## 13691 DFO-444 1019807 cia 2018-02-06 19:40:00 status
## 13692 DFO-444 1008970 epe 2018-01-30 16:32:00 status
## 13693 DFO-444 1008969 epe 2018-01-30 16:32:00 status
## 13694 DFO-444 1008968 epe 2018-01-30 16:32:00 status
## 13695 DFO-444 1008967 epe 2018-01-30 16:32:00 status
## Type From From String
## 11917 jira 14000 Development Completed
## 11918 jirimate Request 10401 Ready
## 11919 jira 10001 To Do
## 13691 jira 14000 Development Completed
## 13692 jira 11702 In Progress
## 13693 jira 10401 Ready
## 13694 jira 14800 Kanban Candidate - Urgent Estimate Request
## 13695 jira 10001 To Do
## To To String
## 11917 12400 Done
## 11918 NA <NA>
## 11919 1480 <NA>
## 13691 12400 Done
## 13692 14000 Development Completed
## 13693 11702 In Progress
## 13694 10401 Ready
## 13695 14800 Kanban Candidate - Urgent Estimate RequestBy coincidence, the rows which have NAs are duplicated, as their History Id repeats. Also, the last two rows with missing values are not relevant either, so we can drop them all.
history <- na.omit(history)
sum(is.na(history))## [1] 0length(duplicated(history)[duplicated(history)=="TRUE"])## [1] 1Apparenty, still have a duplicated value. And once again, belongs to Issue DFO-444. Let’s get rid of it.
history[duplicated(history),]## Issue History Id Author Created Field Type From
## 13691 DFO-444 1019807 cia 2018-02-06 19:40:00 status jira 14000
## From String To To String
## 13691 Development Completed 12400 Donehistory <- unique(history)
length(unique(history$`History Id`))## [1] 18006But I am not too sure about all these unique rows… There are observations where Issues’ Status don’t change, yet get a different History Id.
head(history[history$From==history$To,])## Issue History Id Author Created Field Type From
## 389 TAL-948 1191608 paulo.junior 2018-06-14 15:17:00 status jira 10001
## 442 TAL-938 1166546 rcp 2018-05-28 14:58:00 status jira 12400
## 596 TAL-907 1164729 ase 2018-05-26 01:02:00 status jira 10001
## 658 TAL-894 1185887 ase 2018-06-11 11:30:00 status jira 10001
## 811 TAL-869 1209543 rcp 2018-06-27 13:55:00 status jira 12400
## 1016 TAL-838 1214550 paulo.junior 2018-07-02 15:23:00 status jira 10001
## From String To To String
## 389 To Do 10001 To Do
## 442 Done 12400 Done
## 596 To Do 10001 To Do
## 658 To Do 10001 To Do
## 811 Done 12400 Done
## 1016 To Do 10001 To DoIt doesn’t feel right to me. So, I am going to get rid of these rows too.
history <- history[history$From!=history$To,]In the end, we have 17879 observations for issuesHistory. Although it looks like it is ready to be loaded into the DB, I don’t find it very friendly to have different names for the same From or To IDs, as we can see below:
table(history[history$From=='10401',]$From,history[history$From=='10401',]$`From String`)##
## Estimated & Ready Ready READY
## 10401 60 2177 112For example, for Issue 10401 we see three different From Strings: Estimated & Ready, READY and Ready. Does this happen very often? Below there is a table counting the number of different names each From ID has:
aggregate(data=history, `From String`~From, function(x) length(unique(x)))## From From String
## 1 1 1
## 2 4 1
## 3 10001 2
## 4 10400 1
## 5 10401 3
## 6 10403 1
## 7 10700 1
## 8 11201 1
## 9 11702 2
## 10 11900 1
## 11 11901 1
## 12 12102 1
## 13 12400 1
## 14 13500 1
## 15 13700 1
## 16 13800 2
## 17 13900 2
## 18 13901 1
## 19 14000 1
## 20 14001 1
## 21 14100 1
## 22 14200 1
## 23 14800 1
## 24 14909 1
## 25 185979 1It could be OKish to keep it like this, as a business user can always filter or select records by their From or To IDs, but I guess would be better to standardize it - I will use the most popular names. However, because they might contain relevant information (such as PO Accepted or Estimated), I will save all their former names into two new columns: From Comments and To Comments.
library(dplyr)
#Creation of comments columns
history$`From Comments` <- history$`From String`
history$`To Comments` <- history$`To String`
#Replacement of From/To Strings by their most popular names
history <- history %>% group_by(From) %>% mutate (`From String`=names(which.max(table(`From String`)))) %>% ungroup()
history <- history %>% group_by(To) %>% mutate (`To String`=names(which.max(table(`To String`)))) %>% ungroup()
#If names are the same, there's no need to add any comment. Otherwise, let's keep this information
history$`From Comments` <- ifelse(history$`From Comments`==history$`From String`,"No Comments",history$`From Comments`)
history$`To Comments` <- ifelse(history$`To Comments`==history$`To String`,"No Comments",history$`To Comments`)
head(as.data.frame(history))## Issue History Id Author Created Field Type From
## 1 TAL-1044 1220713 ase 2018-07-05 12:09:00 status jira 10001
## 2 TAL-1044 1220710 ase 2018-07-05 12:09:00 status jira 12400
## 3 TAL-1044 1220545 ase 2018-07-05 12:07:00 status jira 10001
## 4 TAL-1042 1218163 paulo.junior 2018-07-04 15:34:00 status jira 10401
## 5 TAL-1042 1218162 paulo.junior 2018-07-04 15:34:00 status jira 14800
## 6 TAL-1042 1218113 ase 2018-07-04 15:11:00 status jira 10001
## From String To
## 1 To Do 13900
## 2 Done 10001
## 3 To Do 12400
## 4 Ready 11702
## 5 Kanban Candidate - Urgent Estimate Request 10401
## 6 To Do 14800
## To String From Comments To Comments
## 1 Waiting UX / Design No Comments No Comments
## 2 To Do No Comments No Comments
## 3 Done No Comments No Comments
## 4 In Progress No Comments No Comments
## 5 Ready No Comments No Comments
## 6 Kanban Candidate - Urgent Estimate Request No Comments No CommentsThe files are cleaned and ready to be loaded into our DB for further analysis and business use.
write.csv(history, "~/Desktop/history.csv", row.names = FALSE, quote = FALSE)PART 2
Report
Now that we have loaded our data into our DB, we can use SQL queries to answer a few questions, such as:
- How many issues were created in total?
SELECT COUNT(DISTINCT key)
FROM issues;
- How many issues were created that we don’t have historical records for?
SELECT COUNT(DISTINCT key)
FROM (SELECT i.project, i.key, i.type, h.issue
FROM history h
RIGHT OUTER JOIN issues i ON i.key = h.issue)
WHERE issue IS NULL;
- What is the average Time to Close per project, since the moment tickets were first created? (assuming an issue is closed when its status gets Done)
WITH new AS (
SELECT i.project, h.issue, i.created AS created, h.created AS timepoints
FROM history h
INNER JOIN issues i ON i.key = h.issue
WHERE i.status in (‘Done’)),
range AS (SELECT project, issue, MIN(created) created, MAX(timepoints) timepoints FROM new GROUP BY project,issue),
diff AS (SELECT project, issue, DATEDIFF(day, range.created, range.timepoints) days FROM range)
SELECT project, ROUND(AVG(days),0) Days_to_complete
FROM diff
GROUP BY project;
But I’d rather keep investigating the datasets in R, due to its flexibility and data visualization capabilities.
library(readr)
library(dplyr)
library(tidyr)
library(ggplot2)
library(RColorBrewer)
library(treemapify)
issues <- read.csv("~/Desktop/READYissues.csv")
history <- read.csv("~/Desktop/history.csv")
issues$Created <- as.POSIXct(issues$Created, format = "%Y-%m-%d %H:%M", tz="GMT")
history$Created <- as.POSIXct(history$Created, format = "%Y-%m-%d %H:%M", tz="GMT")In total, there are 4247 issues created between 2016-03-23 14:36:00 and 2018-07-06 11:03:00, which are distributed across projects and types the following way:
| Type | CVAL | DFO | DW | GTM | TAL |
|---|---|---|---|---|---|
| Bug | 194 | 338 | 397 | 120 | 189 |
| Bug - Sub-Task | 84 | 12 | 35 | 50 | 0 |
| Epic | 17 | 12 | 34 | 12 | 25 |
| Idea | 7 | 0 | 1 | 0 | 29 |
| Initiative | 1 | 1 | 1 | 2 | 4 |
| Question | 7 | 4 | 11 | 3 | 3 |
| Research | 4 | 2 | 2 | 12 | 13 |
| Story | 280 | 235 | 511 | 240 | 306 |
| Sub-task | 133 | 78 | 145 | 119 | 295 |
| Task | 64 | 20 | 69 | 84 | 40 |
| Technical Sub-Task | 2 | 0 | 0 | 0 | 0 |
DW and TAL are the projects which created the largest amount of issues. Bugs and Stories are the most popular types. Types of issues seem to follow a similar trend across different projects, as suggested in the table above (also represented in the chart below):
Despite the similar distribution of types of issues across projects, is important to highlight the fact that DFO is the one with the largest share of bugs.
But how have issues evolved overtime?
In July 2018 the volume of tickets created plunged because we only have records until 2018-07-06 11:03:00. Would be great to break down this growth in order to better understand its roots.
From May 2017, the volume of tickets increased due to DW. In October 2017, GTM massively contributed to tickets volume and, from November 2017, it increases further due to both CVAL and DFO. But it is because of these two projects that we see a sudden drop in April 2018. Also, TAL gets particularly representative in January and May 2018.
In terms of types of tickets, evolution goes the following way.
Bugs and Stories are the most popular types of tickets, but Sub-Tasks have consistently gained ground recently. Further details in attachments.
And how are tickets creation spread in a month? And in a week? What about in a day?
I believe there’s nothing wrong with the time tickets are created, they follow a fair distribution in a month, week or day.
If we take a closer look at the history and issues files, we realize we lack historical data for 542 tickets. See further analysis in attachments.
But let’s focus our investigation on tickets which have historical data. So, let’s merge both datasets in order to go deeper in tickets’ dynamics.
From all 4247 issues created, we only have historical data for 3705 and only 2341 issues were completed/done. Each ticket follows a specific path to get done, going through different stages and authors, taking different timings. We can get a summary of these metrics by ticket the following way:
hi_resume <- hi %>%
group_by(Project,Issue,Type,Status) %>%
summarise(requested = min(`First Created`), kickoff = min(Created), delivered = max(Created), status_changes=n(), nr_authors = n_distinct(Author)) %>%
mutate(time2kick = as.numeric(round(difftime(kickoff,requested,units="days"),0)), leadtime = as.numeric(round(difftime(delivered,kickoff,units="days"),0)), totaltime = as.numeric(round(difftime(delivered,requested,units="days"),0))) %>% as.data.frame
head(hi_resume)## Project Issue Type Status requested kickoff
## 1 CVAL CVAL-10 Story Done 2017-09-22 15:14:00 2017-09-25 16:22:00
## 2 CVAL CVAL-101 Bug Done 2017-11-15 18:33:00 2017-12-07 12:04:00
## 3 CVAL CVAL-102 Bug Done 2017-11-15 18:39:00 2018-01-10 11:09:00
## 4 CVAL CVAL-104 Story Done 2017-09-04 13:45:00 2017-10-18 14:42:00
## 5 CVAL CVAL-105 Sub-task Done 2017-02-02 14:54:00 2017-11-06 16:22:00
## 6 CVAL CVAL-106 Sub-task Done 2017-09-04 13:39:00 2017-11-06 16:23:00
## delivered status_changes nr_authors time2kick leadtime
## 1 2017-12-13 17:17:00 2 2 3 79
## 2 2018-01-25 16:26:00 5 2 22 49
## 3 2018-01-25 16:22:00 11 3 56 15
## 4 2017-12-19 11:28:00 6 2 44 62
## 5 2017-11-13 19:39:00 4 1 277 7
## 6 2017-11-13 19:39:00 4 1 63 7
## totaltime
## 1 82
## 2 71
## 3 71
## 4 106
## 5 284
## 6 70In my perspective, time can be divided into 3 distinct stages:
1. Requested when the issue was first created in the platform;
2. Kick Off when the first stage of the process was completed and the ticket moved to the next one;
3. Delivered when it reached the last stage in our records, either completed or not.
Therefore, we can come up with 3 metrics:
1. Time2kick tells us two things at once: how long the issue waited in the line until it was first picked up by the first stage, plus how long the first stage took to complete;
2. Lead time which represents the time it took from the second stage until it reached the last stage in our records;
3. Total time which is the sum of the previous two stages, or the time it took since it was created in the platform until it reached the last stage in our records.
We can also get the number of status changes each ticket went through, as well as the number of distinct people who owned them (nr_authors).
From here, we can develop a lot of different views for our data. I am curious about how these new variables correlate with each other… 
Of course total time is highly correlated with both lead time and time2kick. Also, status changes with nr_authors is expectable, as the more stages issues go through, the more distinct people are likely to be involved. However, I was surprised to see that status_changes and nr_authors don’t correlate at all with any of the time variables. Furthermore, I was also expecting to see some kind of correlation between time2kick and leadtime, as per haps the more time consuming issues are, the quicker they would be picked up. But our data doesn’t confirm this relationship.
How are these variables distributed? For example, how does time behave?
Overall, 50% of issues take around three weeks to reach to their last stage (either completed or not). What happens to time variables across Projects? (there are plenty of outliers in our dataset and the maximum value for total time is 739 days, but I will establish shorter y limits for the sake off better viz).
It looks like time doesn’t vary that much across Projects. Below there’s a summary table for each one of the variables above, by project. I used medians as a measure to compare projects, so we can avoid the outliers effect.
| Project | status_changes | nr_authors | time2kick | leadtime | totaltime |
|---|---|---|---|---|---|
| CVAL | 6 | 2 | 5 | 8 | 21 |
| DFO | 4 | 2 | 2 | 3 | 15 |
| DW | 3 | 2 | 3 | 8 | 28 |
| GTM | 4 | 2 | 1 | 5 | 15 |
| TAL | 6 | 2 | 5 | 8 | 21 |
DFO and GTM are the projects where issues are taken care more quickly. It is impressive how time2kick weights so much over totaltime for CVAL and TAL. It means that either these projects take so long to pick issues up, or their first stage is very time consuming.
One hypothesis is that it might depend on the types of issues they usually deal with. We will further investigate their relationship in a while, but before that, I want to execute the same view for types of issues only.
| Type | status_changes | nr_authors | time2kick | leadtime | totaltime |
|---|---|---|---|---|---|
| Bug | 2.0 | 1.0 | 5.0 | 0 | 19.0 |
| Bug - Sub-Task | 7.0 | 2.0 | 0.0 | 6 | 8.0 |
| Epic | 1.0 | 1.0 | 121.0 | 0 | 181.0 |
| Idea | 1.0 | 1.0 | 100.5 | 0 | 123.0 |
| Initiative | 2.0 | 2.0 | 220.5 | 44 | 318.0 |
| Question | 1.0 | 1.0 | 1.0 | 0 | 2.0 |
| Research | 1.0 | 1.0 | 20.0 | 0 | 20.0 |
| Story | 5.0 | 2.0 | 4.0 | 15 | 30.0 |
| Sub-task | 7.0 | 2.0 | 1.0 | 6 | 11.5 |
| Task | 3.0 | 1.0 | 16.0 | 1 | 36.0 |
| Technical Sub-Task | 12.5 | 2.5 | 9.0 | 9 | 18.0 |
Epic, Idea and Initiative issues show a lot of variability and much higher total time, when compared to other types such as Bugs or even Questions. A plausible reason for this situation is the fact that these types of tickets are more complex and time consuming to implement, than fixing bugs, for example.
But how do types of issues relate with projects?
Here we can see one of the reasons why DFO and GTM see their issues being solved quicker than remaing projects: the types of issues which take a long time are not created under DFO and GTM.
Bugs, stories and sub-tasks take approximately the same time to be solved across projects. Research in CVAL and Epics in TAL take forever…
Meanwhile, another question comes up: what about the difference between tickets which were solved by the time of this extraction and the ones which are still pending?
Firstly, a quick look at volumes… (further details here) 
More than half of DFOs’ stories haven’t been solved yet. Sub-tasks (including Bugs and Technical) are extraordinarily successful in their completion.
I think would be valuable to perform a similar analysis for our metrics, taking into consideration the issues which were solved and the ones still to be completed. 
Issues for CVAL and TAL projects take too long to be picked up. They deal with Epics and Ideas more than their counterparts, but that shouldn’t be the only reason, as volumes of these types are low. The trend also happens for Stories, for example, where these projects take some time to start off:
| Project | time2kick |
|---|---|
| CVAL | 6 |
| DFO | 2 |
| DW | 3 |
| GTM | 1 |
| TAL | 9 |
| Note: | |
| Data for Stories only. |
CVAL and TAL take a median of 6 to 9 days to kick off Stories, respectively.
What about the distribution of time to kick off by type? How does it look like?
Again, to confirm my previous statement, the longer issues take to kick off, the less chances they have to get completed. Initiatives, for example, never got done! Conversely, Technical Sub-Tasks were all completed.
Therefore, I believe that the kick off moment is extraordinarily important in predicting whether issues will be solved and how fast this will happen. So, it is key to deep dive into the first stage of the process.
Typically, the first stages of the process are To Do and Screen Issue. There are a few issues which start off with different stages, but for the purpose of our analysis, we can ignore these exceptions and focus on these two. In fact, 99.76% of total issues start either on To Do or Screen Issue.
More than half of issues which start at Screen Issue don’t get done. Overall, how long does this step usually take?
| From.String | time |
|---|---|
| Screen Issue | 35 days |
| To Do | 2 days |
When an issue starts with To Do, it usually takes 2 days to pass onto the next stage, whereas when it starts with a Screen it takes around 35 days. The difference gets even larger if we consider the issues which are successfully completed.
| From.String | No | Yes |
|---|---|---|
| Screen Issue | 63.5 days | 15 days |
| To Do | 3.0 days | 2 days |
The Projects which are most affected by this delay are DW, CVAL and TAL.
The Types of issues which are most affected by screen issue’s delay are Bugs and Stories. 
Further details here
Final Thoughts
- The dynamics analyzed above suggest there is a hierarchical order for types of issues;
- The first stage in the process is a key moment - it highly affects total time of tickets’ completion. The quicker they are picked up, the higher the chances they will be solved whithin a reasonable timeframe;
- The Screen Issue stage is the bottleneck. It is the stage where tickets take the longest time to progress, when compared to remaining first stages. I would recommend assigning more collaborators to this step;
- Epics, Ideas and Initiatives take much longer to develop than remaining types of issues, as they depend on the completion of certain types of issues to proceed.
Attachments
Missing Historical Data
Below, we see the number of tickets by type and project where historical data is missing: 
Historical data is missing across all projects and types of issues, except for Bug-Sub-Tasks and Technical Sub-Tasks. However, status are not distributed the same way… 
Interestingly, from all 2341 issues completed, we don’t have historical data for only 1 of them:
subset(issues[issues$Status=="Done",], !(Issue %in% hi[hi$Status=="Done",]$Issue))## Project Issue First Created Status Type month day
## 4247 CVAL CVAL-1 2017-10-04 20:07:00 Done Bug 2017-10 04
## day_of_week hour
## 4247 Wednesday 21Issues solved, by Project and Type
| CVAL | DFO | DW | GTM | TAL | |
|---|---|---|---|---|---|
| Bug | 89 | 120 | 213 | 39 | 104 |
| Bug - Sub-Task | 84 | 8 | 31 | 46 | 0 |
| Epic | 1 | 0 | 11 | 0 | 0 |
| Idea | 0 | 0 | 0 | 0 | 10 |
| Initiative | 0 | 0 | 0 | 0 | 0 |
| Question | 2 | 2 | 4 | 2 | 2 |
| Research | 0 | 0 | 1 | 5 | 11 |
| Story | 161 | 43 | 229 | 152 | 183 |
| Sub-task | 91 | 53 | 118 | 105 | 273 |
| Task | 27 | 7 | 36 | 43 | 32 |
| Technical Sub-Task | 2 | 0 | 0 | 0 | 0 |
| Type | CVAL | DFO | DW | GTM | TAL |
|---|---|---|---|---|---|
| Bug | 0.53 | 0.51 | 0.58 | 0.34 | 0.58 |
| Bug - Sub-Task | 1.00 | 0.67 | 0.89 | 0.92 | 0.00 |
| Epic | 1.00 | 0.00 | 0.44 | 0.00 | 0.00 |
| Idea | 0.00 | 0.00 | 0.00 | 0.00 | 0.42 |
| Initiative | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| Question | 0.67 | 1.00 | 0.44 | 0.67 | 0.67 |
| Research | 0.00 | 0.00 | 0.50 | 0.45 | 0.85 |
| Story | 0.68 | 0.24 | 0.49 | 0.68 | 0.68 |
| Sub-task | 0.88 | 0.68 | 0.89 | 0.89 | 0.94 |
| Task | 0.57 | 0.50 | 0.60 | 0.56 | 0.80 |
| Technical Sub-Task | 1.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| Type | CVAL | DFO | DW | GTM | TAL |
|---|---|---|---|---|---|
| Bug | 5 | 3 | 6.0 | 4 | 5.5 |
| Bug - Sub-Task | 1 | 0 | 1.0 | 0 | 0.0 |
| Epic | 0 | 0 | 71.0 | 0 | 0.0 |
| Idea | 0 | 0 | 0.0 | 0 | 11.0 |
| Question | 1 | 105 | 0.5 | 3 | 7.5 |
| Research | 0 | 0 | 0.0 | 0 | 20.0 |
| Story | 5 | 11 | 1.0 | 0 | 9.0 |
| Sub-task | 4 | 0 | 0.0 | 1 | 1.0 |
| Task | 9 | 21 | 18.5 | 6 | 5.5 |
| Technical Sub-Task | 9 | 0 | 0.0 | 0 | 0.0 |
| Type | CVAL | DFO | DW | GTM | TAL |
|---|---|---|---|---|---|
| Bug | 17 | 5.5 | 2.0 | 0 | 6.0 |
| Bug - Sub-Task | 6 | 0.5 | 12.0 | 5 | 0.0 |
| Epic | 2 | 0.0 | 146.0 | 0 | 0.0 |
| Idea | 0 | 0.0 | 0.0 | 0 | 14.5 |
| Question | 0 | 0.0 | 0.0 | 0 | 0.0 |
| Research | 0 | 0.0 | 8.0 | 14 | 0.0 |
| Story | 20 | 12.0 | 26.0 | 16 | 20.0 |
| Sub-task | 6 | 4.0 | 8.0 | 7 | 6.0 |
| Task | 8 | 0.0 | 9.5 | 0 | 15.0 |
| Technical Sub-Task | 9 | 0.0 | 0.0 | 0 | 0.0 |
Issues solved vs not solved when Screen Issue as first stage
| CVAL | DFO | DW | GTM | TAL | |
|---|---|---|---|---|---|
| Bug | 0.36 | 0.11 | 0.69 | 0.40 | 0.30 |
| Bug - Sub-Task | 1.00 | 0.00 | 1.00 | 0.00 | 0.00 |
| Epic | 0.00 | 0.00 | 0.48 | 0.00 | 0.00 |
| Idea | 0.00 | 0.00 | 0.00 | 0.00 | 0.07 |
| Initiative | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| Question | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| Research | 0.00 | 0.00 | 0.50 | 0.00 | 0.00 |
| Story | 0.15 | 0.12 | 0.50 | 0.23 | 0.33 |
| Sub-task | 0.57 | 0.00 | 0.82 | 1.00 | 0.00 |
| Task | 0.09 | 0.00 | 0.58 | 0.00 | 0.60 |
| Technical Sub-Task | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |